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MAJORITY OF ENTERPRISE RESOURCE PLANNING (ERP) 
PROJECTS FAIL - M-DCPS IS A RARE EXCEPTION 


At a Glance 

A high percentage of ERP projects are classified as failures, leaving organizations with only 
partially functioning systems or, worse yet, with no ERP systems at all. Those that do succeed 
usually take significantly longer than expected and encounter staggering budget overruns. 
This Information Capsule summarizes 1 0 high profile ERP implementation failures that occurred 
over the last few years. In addition, the 10 factors most frequently associated with ERP system 
failures are reviewed. Finally, a brief description of the implementation of Miami-Dade County 
Public Schools' (M-DCPS) ERP system is provided. Contrary to the many failed experiences 
chronicled nationwide, M-DCPS' story is one of success. The District's Office of Information 
Technology (ITS) implemented all five modules of M-DCPS' ERP system in less than three 
years. Although final judgment on the efficacy of the ERP system cannot be made for at least 
another year, ITS staff were able to complete the project in a timely manner and within the 
District's original budget. 


A January 2009 Information Capsule, Enterprise Resource Planning (ERP) Implementation Experiences 
in Large School Districts, is available at http://drs.dadeschools.net . The Information Capsule summarizes 
ERP implementation experiences from several large school districts in Florida and across the country. 


Many organizations have multiple and unconnected databases that do not share information with each 
other. In order to eliminate this problem, a new breed of software systems, called Enterprise Resource 
Planning (ERP), was created. ERP systems allow organizations to integrate data and processes from all 
areas of the organization and unify them for easy access. ERP systems usually accomplish this integration 
by creating a single database that uses many software modules. Each module provides different areas 
of the organization with various business functions (Bhagwani, 2009; Wong & Tein, 2003). 

Since the 1 990s, more and more organizations have turned to ERP systems to replace obsolete processes 
and improve their performance (Bhagwani, 2009). A CIO magazine survey of 400 IT executives who 
installed ERP systems found that more than 85 percent agreed or strongly agreed that their ERP systems 
were essential to the core of their business and that they “could not live without them.” Over three- 
quarters of respondents stated that operational efficiency was the main reason why they invested in an 
ERP system. Ninety-six percent reported using their ERP systems primarily for financial applications 
(Wailgum, 2008). 
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Despite the promise of ERP applications, studies have found that a high percentage of ERP 
implementations are classified as failures (Kanaracus, 2011 a; Hickey, 2010; Industry Week, 2008; Wong 
& Tein, 2003). Wailgum (2009) noted that implementation of ERP systems in many organizations is 
characterized by “troubled multimillion dollar software deals that produce spectacular failures and huge 
spending nightmares; vendor marketing bravado that breeds cut-throat competition and contempt; and 
embarrassing and costly lawsuits over botched implementation and intellectual property breaches.” 
Panorama Consulting predicted an increase in the number of ERP failures and lawsuits for 201 2 (Kimberling, 
2011a). 

Highlighted below are the results of several surveys on organizations’ experiences with ERP 
implementation. These surveys found that many organizations fail in their efforts to implement ERP 
systems, with the majority of projects taking longer and costing more than expected. 

• In 201 0, the Standish Group surveyed companies that had implemented 1 0,000 technology projects 
worldwide. They found that only 37 percent of projects were successful (defined as coming in on 
time and on budget). Forty-two percent of projects were reported as being “challenged” (over 
budget, late, or with less-than-required features and functions). Twenty-one percent of projects 
were considered complete failures (canceled prior to completion or delivered but never used). In 
addition, over half (53 percent) of the projects were reported to cost 189 percent of their original 
estimates (Fister Gale, 2011). 

• Panorama Consulting Group (2011) found that ERP projects took longer than expected at 61 
percent of the 185 companies they surveyed. Costs exceeded budgets at 74 percent of the 
companies. An earlier survey of 24 companies conducted by Panorama in 2006 found that 100 
percent of the companies went over budget on their ERP implementations. Seventy-eight percent 
of the companies reported that they went over budget by at least 10 percent, and the average 
reported cost overrun was 23 percent. Kimberling (2006) speculated: “It could mean that the 
companies all under-budgeted. Or it could mean that they didn’t manage the project well. Or, 
maybe vendors mismanaged their side of the implementation. Of course, it could have been all of 
the above.” 

• Ellis (2008) studied over 1 00 companies that implemented technology projects. His Business Analysis 
Benchmark report concluded that the success of technology projects was strongly related to 
companies’ ability to accurately analyze their business requirements. Ellis’ study concluded that 68 
percent of the companies had low levels of business analysis skills and were therefore unlikely to 
complete a successful technology project. In fact, Ellis predicted that companies with poor business 
analysis skills would have three times as many project failures as successes. The technology 
projects at half of the companies with poor business analysis skills were characterized by two of the 
following three factors: the project took over 180 percent of the target time to deliver; the project 
consumed in excess of 160 percent of the estimated budget; and the project delivered under 70 
percent of the required functionality. 

• Glomark-Governan’s ERP Research Study (2008) of 250 companies worldwide found that prior to 
implementing ERP systems, 85 percent of organizations failed to prepare an objective analysis that 
weighed the economic costs and benefits of such systems and identified risk factors that could 
potentially lead to project failure. The study also found that on average companies used less than 
60 percent of the features available in their ERP systems. 
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TEN HIGH PROFILE ERP SYSTEM FAILURES 


Ten high profile ERP implementation failures that have occurred over the last few years are summarized 

below. 

1 . CityTime. The CityTime project was implemented to modernize New York City’s payroll system by 
substituting computerized timekeeping for paper records. The project began in 2003 with a budget 
of $63 million. By 2011, project costs had reached $760 million and staffing levels had more than 
doubled. In May 2011, federal prosecutors in Manhattan began indicting former employees of 
systems integrator Science Applications International Corporation (SAIC) and its subcontractor, 
TechnoDyne, for participating in a fraud scheme that siphoned approximately $80 million from 
taxpayers. Much of TechnoDyne’s operations and many of its employees have been transferred to 
India, where they are unavailable to U.S. officials. In December 2011, SAIC reported that it set 
aside a $232 million loss provision in connection with the case. Approximately 165,000 New York 
City employees are currently on the CityTime system. The cost per user is approximately $4,000 
(Halbfinger, 2011 ; Kanaracus, 2011a; Kanaracus, 2011b; Saul, 2011). 

The New York Times (2011) stated: “An examination of the events that led to the CityTime scandal 
reveals lax oversight, mismanagement, and a basic failure to control costs.” The newspaper also 
reported that CityTime switched from a fixed-price contract, in which a negotiated amount was paid 
for services delivered, to an hourly one. Costs then climbed from $224 million in 2006 to $628 
million in 2009. 

2. Montclair State University. The university entered into a contract with Oracle in 2009 for a 
PeopleSoft suite designed to replace its 25-year-old set of legacy applications. According to the 
contract, Oracle received a fixed fee for implementation services ($1 5.75 million), plus approximately 
$4.3 million for software and support. The following year, Oracle asked Montclair for an additional 
$8 million to complete the job and threatened to pull its staffers off the project if a new agreement 
was not reached. Montclair terminated its contract with Oracle in November 201 0. 

In May 2011, Montclair sued Oracle, claiming that the company “failed to deliver key implementation 
services, caused critical deadlines to be missed, refused to make available computer resources 
that it had promised, failed to deliver properly tested software, and overall, failed to manage properly 
the project.” The university also contended that Oracle continually rotated staff in and out of the 
project, causing confusion and wasted effort. Based on bid responses by replacement vendors, 
Montclair estimated that it will cost between $1 0 to $20 million to finish the project. 

Oracle countersued, claiming that the university was to blame for the project’s problems. They 
maintained that the university’s leadership did not adequately understand the technology and the 
steps necessary to complete the project. In December 201 1 , Montclair filed an amended complaint, 
claiming that Oracle made “intentionally false statements” regarding the functionality of the ERP 
system, the amount of customization that would be required, and the amount of “time, resources, 
and personnel that the University would have to devote.” The legal battle continues. In January 
2012, Oracle filed a motion to dismiss Montclair’s claims (Kanaracus, 2012a; Kanaracus, 2011a; 
Kanaracus, 2011c; Kanaracus, 2011 d). 

3. Marin County, California. In February 2011, the government of Marin County, California, sued 
Deloitte and SAP in federal court, claiming they had “engaged in a pattern of racketeering activity” 
aimed at bilking the county out of more than $20 million in connection with its failed ERP project. 
The lawsuit alleged that Deloitte and SAP were in violation of the federal Racketeer Influenced and 
Corrupt Organizations (RICO) act. Marin County had originally sued Deloitte in 2010 and later 
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named SAP in the suit. The 2010 suit claimed that Deloitte had used the project as a “trial-and- 
error training ground” for inexperienced employees, and the result was a “costly computer system 
far worse than the legacy systems it was intended to replace.” Marin County maintained that four 
years after going live, the SAP Financial, Pluman Resources, and Payroll modules Deloitte designed 
and installed did not function properly and continued to significantly hamper county operations. 

Deloitte has denied any culpability. The company claims it delivered a working system to Marin 
County and that the county failed to claim any problems in a timely manner, as required by its 
contract. In December 2011 , a judge ruled that Marin County failed to allege sufficient facts to bring 
a racketeering claim against SAP under the terms of the RICO act, although the county will be 
allowed to file an amended complaint to correct the deficiencies in its claim. Since this latest ruling 
eliminates the RICO charges, Marin County’s complaint is now a conventional lawsuit and the 
parties will argue their claims until one or the other prevails. 

In the meantime, Marin County has decided to replace its SAP software with a new system. The 
county estimated that maintaining the system at status quo, with no fixes or upgrades, would cost 
up to $34.7 million over 10 years. Fixing the system and supporting continual improvement by 
hiring additional workers would cost $49.8 million. In contrast, installing a new system would cost 
just $26.2 million over the same 10-year period (Kanaracus, 2011 e; Claburn, 2010; Hickey, 2010; 
Hoge, 2010; Wood, 2010a). 

4. Whaley Foodservice Repairs. Whaley Foodservice Repairs of South Carolina sells and fixes 
equipment used by commercial kitchens. In August 2011, Whaley filed suit against the software 
vendor Epicor for failure to implement its ERP system. Whaley began contract negotiations with 
Epicor in 2006 and the ERP system was scheduled to go live in Whaley’s home office as well as 1 2 
branch locations by March 2007. Flowever, implementation was delayed multiple times and the 
system was never fully functional in more than two years of use. In addition, the project’s 
implementation topped $1 million, or five times the original estimate of $1 90,000. Whaley’s lawsuit 
claimed fraud, breach of contract, unfair trade, and negligent misrepresentations. In addition, the 
suit claimed that Epicor’s implementation team suffered from high turnover and that Whaley was 
forced to hire a third party software developer to fix software defects. Whaley asked that its money 
be returned and requested additional monetary compensation for damages. Epicor has denied 
any wrongdoing and maintains that under the terms of the contract, Whaley still owes them more 
than $283,000 (Kanaracus, 201 If; Kimberling, 2011b). 

5. Waste Management Incorporated. Waste Management, Incorporated offers collection, transfer, 
recycling, disposal, and waste-to-energy services across the U.S. The company sued SAP for 
fraud in March 2008 over the failed implementation of its ERP software and a two-year legal battle 
ensued. Waste Management claimed SAP demonstrated a fake product and tricked it into believing 
the software would meet the company’s needs without any customization or enhancements. Waste 
Management stated that SAP knew the software was “unstable and lacking key functionality.” Waste 
Management’s complaint alleged that it suffered significant damages, including more than $100 
million it spent on the project, plus $350 million for benefits it would have gained had the software 
worked as intended. 

In its defense, SAP said that Waste Management did not “timely and accurately define its business 
requirements” or provide “sufficient, knowledgeable, decision-empowered users and managers” to 
the implementation. SAP and Waste Management reached a confidential settlement agreement in 
March 2010 (Binstock, 2010; Kanaracus, 2010; Wood, 2010b; Bhagwani, 2009; Wailgum, 2009). 
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6. ParknPool. In November 2011 , commercial outdoor furniture seller ParknPool filed a lawsuit against 
Epicor for failing to implement its ERP system. The suit also named Epicor’s partner, EstesGroup, 
which performed systems integration work on the job. According to ParknPool, Epicor told them 
that its current hardware set-up would be sufficient and that a fully functional system would be 
installed within seven weeks. After seven months, the ERP system was still not functioning and a 
glitch in the system caused ParknPool’s sales representatives to be paid double commissions. 
Epicor initially claimed that the project could be completed with a specific set of software modules, 
but then said that additional modules were required after the project started. For example, according 
to ParknPool’s administrative manager: “We had to buy the manufacturing module in order for the 
payroll [module] to work. We don’t do any manufacturing.” 

EstesGroup told ParknPool that it had the ability to complete the project, but asked that the company 
terminate its contract with Epicor and deal with EstesGroup directly. ParknPool then signed a contract 
with EstesGroup but the company was unable to complete the job. ParknPool’s lawsuit is asking for 
$250,000 in damages along with attorney’s fees and other monies. According to ParknPool’s 
administrative manager, the company is still using its legacy accounting system and has no immediate 
plans to implement another ERP system. Epicor denies the allegations made by ParknPool in its 
suit (Kanaracus, 2011a; Kanaracus, 2011 g). 

7. Major Brands. Beverage distributor Major Brands filed suit against Epicor in January 201 2, alleging 
breach of contract and negligent misrepresentation. The company is asking for damages and 
restitution, as well as for the contract between itself and Epicor to be rescinded. Major Brands 
claimed that Epicor said the ERP applications would be fully installed and running in production 
form by mid-2011 . However, by November 2011 , latency problems with the software led Epicor to 
acknowledge that the software was not suitable for Major Brands’ needs and that it would not 
perform as previously represented. According to Major Brands’ complaint, Epicor told them it would 
need to make numerous changes, including an upgraded and yet-to-be-developed computer 
software platform. Epicor’s revised implementation plan called for a new go live date of mid-2015, 
pushing back the original go live date by four years, and resulting in over $1 million in additional 
costs. Epicor has not yet responded to requests for comment (Kanaracus, 2012b). 

8. CareSource Management Group. CareSource Management Group, a Dayton, Ohio, health care 
plan administrator, signed a contract with Lawson Software in August 2010 for an ERP system. In 
June 201 1 , CareSource sued Lawson, claiming that after 1 0 months, the system had not advanced 
beyond the testing phase and was not the fully integrated suite Lawson had promised to deliver. 
Instead, the system consisted of two separate modules and severe data transfer problems arose 
between those two modules. CareSource’s complaint alleged that Lawson failed to provide them 
with a workable time-and-attendance application after proposing two products that proved unsuitable. 
In addition, CareSource claimed that Lawson assigned inexperienced staff to the job. CareSource 
is demanding at least $1.5 million in damages. Lawson filed a counterclaim in September 2011, 
denying any wrongdoing. Lawson acknowledged that “certain issues” occurred with the modules’ 
integration but that they were resolved. Lawson is seeking more than $335,000 in unpaid fees. The 
legal fight is ongoing (Kanaracus, 201 1 h). 

9. Idaho. According to a report released by Idaho’s Office of Performance Evaluations, the state may 
lose millions of dollars due to problems with a new ERP system for processing Medicaid claims. 
Idaho’s Department of Health and Welfare contracted with Unisys in 2007 to develop the system, 
which handles claims submitted by health care providers who treat Medicaid patients. [In 2010, 
Molina Healthcare acquired the Unisys unit involved in Idaho’s ERP project and assumed control of 
the project.] Idaho’s Office of Performance Evaluations stated that once the system went live in 
June 2010, “a series of design defects, provider enrollment issues, and a lack of coordination to 
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resolve issues led to months of payment delays and inaccurate processing of claims.” The report 
added that the ERP project suffered from “unclear contract requirements, a lack of system readiness, 
and the absence of adequate end user participation throughout the enrollment and testing phases.” 
Idaho sent out over $1 00 million in advance payments to providers while trying to solve the system’s 
problems. It has since tried to get that money back, but $2 million was “at risk of not being recouped 
at all,” according to the auditor. The auditor concluded that the root cause of the problems was that 
the system went live before certain testing milestones had been reached (Kanaracus, 201 1 i). 

1 0. Pennsylvania Liquor Control Board (PLCB). The PLCB oversees the wholesale and retail sale 
of alcohol in Pennsylvania through a chain of state-run retail stores. In August 2007, the PLCB 
decided to install Oracle ERP software and use Deloitte as the systems integrator. The original 
contract was for $25.8 million, but subsequent amendments to the contract increased the cost to 
$60.6 million in June 2009, and by another $6 million in June 2010. This represented an increase 
of 150 percent over the initial cost. A forecasting application went live in September 2009 and by 
January 201 0, managers learned that the system was producing inaccurate inventory levels. PLCB 
officials asked Oracle for the inventory forecasting formulas to resolve the problem, but were denied 
on the grounds that the information was proprietary. The PLCB was forced to order excess 
merchandise to compensate for the system’s flaws, resulting in overflowing stocks and high storage 
costs. 

A report published by Pennsylvania’s auditor general stated that the ERP project was “marred by 
inflated costs, staffing woes and operational problems.” The auditor general noted that although 
PLCB’s sales rose during this period, their net profits from store operations dropped 47 percent. 
The audit concluded that problems with the ERP system “appear to be one of the primary causes 
for this major downturn in profits.” Oracle appears to consider this project a success, naming the 
PLCB one of its Retail Excellence award winners. The PLCB declined to comment (Bohren, 2011 ; 
Kanaracus, 201 1 j). 

TEN FACTORS MOST FREQUENTLY ASSOCIATED WITH ERP SYSTEM FAILURE 

ERP failures can be influenced by many factors. In most cases, it is impossible to assign blame solely to 
one party, but in some instances the fault lies mainly with software vendors or systems integrators; in 
others, the organization implementing the ERP system engages in practices that contribute to project 
failure. Analyses of the failed ERP implementations summarized above, as well as other ERP failures 
across a wide variety of industries, have resulted in the identification of 10 factors that most frequently 
lead to ERP system failure. 

1. Inexperienced consultants. The practice of system integrators assigning inexperienced 
consultants to ERP projects is so common that almost every lawsuit claims this as a cause of 
action. Since integrators usually charge by the hour, the cheapest staff that can do the job result in 
the greatest profit. Inexperienced consultants are unable to provide professional advice on ERP 
planning and cannot deliver effective training to an organization’s staff members (Kanaracus, 2011 a; 
Binstock, 2010; Wood, 2010c; Bhagwani, 2009; Wong et al. , 2005). 

2. Budget overruns. ERP vendors, in an effort to make their bids more competitive, have been 
known to underestimate the complexity of implementation and suggest unrealistic budgets to potential 
clients. Organizations that have implemented ERP systems voted the following areas as most likely 
to result in budget overruns: staff training; integration and testing of the links between ERP packages; 
software customization; conversion of data from the legacy system to the ERP system; integration 
of the data warehouse with data from the ERP system; and external consulting assistance needed 
after modules go live (Fister Gale, 2011 ; Koch & Wailgum, 2007; Ligus, 2004). 
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Experts suggest that organizations negotiate fixed-price contracts, instead of hourly fee agreements. 
They have seen an increase in the number of fixed-price ERP contracts over the past few years, 
but caution that it is common practice for vendors to increase their budgets by 20 to 30 percent 
when negotiating fixed-price contracts (Kroll, 2012; Kanaracus, 2010). 

3. Unreasonable timelines. Many organizations underestimate the time it will take to complete their 
ERP projects. Some ERP projects fail because organizations rush through critical project activities, 
such as systems configuration, documentation, and testing before going live, in order to meet 
unreasonable deadlines. Experts caution that although small, targeted projects may be ready for 
use within three to six months, large multidimensional implementation usually takes several years 
(Wood, 2010c; Hirsch, 2007; Koch & Wailgum, 2007; Wong et al. , 2005; Ligus, 2004). 

4. Unrealistic expectations. Organizations often assume that implementation of ERP systems will 
solve many of their performance problems, but do not consider the complexity of the implementation 
process or the complications and risks associated with implementation (Kanaracus, 2010; Hirsch, 
2007; Wong et al., 2005). Binstock (2010) concluded that a consistent theme in failed ERP projects 
is overreaching on the part of the organization. He noted: “This ambition is often fueled by 
salespeople from the integrator and the software vendor, who tend to create improbable success 
scenarios and encourage oversized projects.” 

5. Simultaneous module rollout and bad go live timing. ERP implementations often fail when 
organizations go live with all enterprise applications simultaneously. ERP implementation should be 
divided into manageable pieces and the number of applications rolled out concurrently should be 
based on the organization’s implementation resources (Wood, 2010a; Hirsch, 2007). 

Panorama Consulting Group (2011) identified three approaches organizations use to roll out their 
ERP systems: big bang (the ERP system goes live simultaneously with all modules and offices at 
one time); phased (the system goes live in sequence, generally by location or module); or hybrid 
(the system is implemented in a phased manner in some areas and a big bang manner in other 
areas). Panorama’s survey of 1 85 organizations that implemented ERP systems in 201 0 found that 
53 percent reported using the phased approach; 35 percent reported using the big bang approach; 
and 11 percent reported choosing the hybrid approach. 

Problems also arise when organizations fail to take go live timing into account. For example, the 
University of Massachusetts Amherst’s online registration system went live and crashed the day 
before fall semester classes began. The system stayed down for four days at the most crucial time 
of year, when 24,000 students arrived on campus and needed to register for classes, access their 
financial aid checks, and perform other online activities (Wood, 2010c; Wailgum, 2005). 

6. Excessive software customization. Experts warn that too much customization can violate the 
integrity of the software and result in project delays, budget overruns, and an unreliable system (Binstock, 
2010; Wood, 2010c; Bhagwani, 2009; Wong et al., 2005; Enterprise Resource Planning, n.d.). Koch 
and Wailgum (2007) stated: “The horror stories you hear in the press about ERP can usually be traced 
to the changes the company made in the core ERP software to fit its own work methods.” 

However, many organizations believe the ERP software they are installing is too rigid or restrictive. 
They rely on customization to modify the software to fit their unique organizational processes. 
Panorama Consulting Group’s (2011) survey of 185 organizations found that only 15 percent of 
companies reported that they did not customize software. The remaining 85 percent said they 
chose at least some customization, although the majority of these respondents reported only minor 
customization. 


7 


7. Lack of senior management commitment and support. One of the frequently cited reasons 
for ERP project failures is lack of senior management commitment and support (Wood, 2010c; 
Bhagwani, 2009; Hirsch, 2007; Wong et al., 2005; Ligus, 2004). Enterprise Resource Planning 
(n.d.) stated: “Executive sponsors cannot stand on the side lines merely watching the game. They 
must visibly, vocally and actively demonstrate leadership, commitment to the project and support of 
project team members at every possible point. They must quickly intervene to resolve obstacles 
and champion the project’s forward movement.” 

8. Poor project management and control. Project managers should be involved in every aspect 
of the ERP implementation and monitor project activity carefully. Project risks must be identified 
immediately, appropriate resources provided as needed, and personnel and other issues resolved 
as they arise (Binstock, 2010; Wood, 2010a; Bhagwani, 2009; Hirsch, 2007; Enterprise Resource 
Planning, n.d.). Wong and colleagues (2005) found that failure to plan, lead, manage, and monitor 
system implementation was a common factor in unsuccessful ERP projects. Their study of four 
anonymous companies that failed in their implementation of ERP systems concluded that none of 
the project managers exercised effective control of their programs. 

9. Project team turnover. Many ERP implementations suffer from high staff turnover. Experts have 
noted that losing team members results in insufficient knowledge and skill transfer among staff and 
increases the risk of project failure. Some organizations attempt to save money by hiring fewer staff 
to work longer hours on an overtime basis, often extending individual work loads by up to 150 
percent. But studies have found that when staff are required to put in extensive hours over a long 
period of time, they are more likely to experience burnout and resign (Wong et al., 2005; Ligus, 
2004; Enterprise Resource Planning, n.d.). 

10. Inadequate employee training. ERP-related training is crucial since employees must learn new 
software interfaces and business processes which affect the entire organization’s operation. However, 
organizations often do not anticipate the difficulty employees will have transitioning from a legacy 
system to an ERP system and cut corners on training or rush the training schedule (Binstock, 
2010; Wood, 2010c; Industry Week, 2008; Ligus, 2004; Enterprise Resource Planning, n.d.). 

Lumber Liquidators is an example of the negative impact inadequate training can have on ERP 
implementation. The company attributed a net income drop of 45 percent for the third quarter of 
2010 relative to the previous year to reduced productivity following the implementation of its ERP 
system. Their earnings press release stated that insufficient attention to training on the ERP system 
appeared to have caused the difficulties (Krigsman, 2010). 

POST IMPLEMENTATION PROBLEMS 

Contrary to what many organizations believe, an ERP project is not completed when the system goes 
live. Experts have found that the time immediately following go live represents a particular challenge for 
organizations. Benchmarking Partners (1998) conducted a survey of 62 companies that had gone live 
with their ERP systems. Major surprises these companies experienced after they went live with their 
systems included: 

• There was a temporary dip in business performance immediately after ERP systems went live. 

• Management observed that employees seemed to forget much of what they had learned in training. 

• Staff described an environment of “chaos,” lasting from three to nine months, as they tried to learn 
the new ERP system. 
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• ERP software did not always function as promised. 

In many organizations, the ERP project team is dismantled as soon as the system goes live. Experts 
recommend, however, that the project team be kept together in order to maintain continuity throughout 
the post go live activities (Kavanagh, 2006; Benchmarking Partners, 1998). Koch and Wailgum (2007) 
cautioned that when organizations let ERP project staff go immediately following go live, they usually 
wind up hiring them back as consultants for twice the salary they originally paid them. The researchers 
discovered that a “frenzy of post-ERP installation activity,” such as writing reports to extract information 
from the new ERP system, kept project teams busy for at least one additional year. 

Many studies have found that when ERP systems are first installed, employees actively resist the changes 
and try to continue doing their jobs the old, comfortable way. Employee resistance to change is often 
caused by unfamiliarity with the rationale for implementing the ERP system in the first place; lack of user 
involvement in decisions relating to implementation; lack of visible top management support and 
commitment; and insufficient user training and education (Bhagwani, 2007; Wong et al., 2005; Ligus, 
2004; Benchmarking Partners, 1998). 


ON A LOCAL NOTE 

Miami-Dade County Public Schools’ (M-DCPS) ERP project was successfully completed by the District’s 
Office of Information Technology Services in November 201 1 . The ERP system, through its SAP (Systems, 
Applications and Products) software, provides technology solutions that integrate the District’s data and 
processes into a single unified system. M-DCPS’ ERP system consists of five modules: Organizational 
Management and Personnel Administration (OMPA), E-Recruiting, Finance/Procurement, Pluman 
Resources, and Payroll. 

M-DCPS’ ERP system was approved by The School Board of Miami-Dade County in December 2005 as 
part of the District’s Comprehensive Technology Information Blueprint. In July 2007, the School Board 
approved Deloitte Consulting to provide implementation services for the ERP software and awarded a 
contract to Banc of America Public Capital Corporation to finance the project for up to $85.4 million. The 
School Board approved the engagement of KPMG in July 2008 to perform independent project monitoring 
services. Specifically, KPMG was retained in order to identify project improvement opportunities, risks, 
and conditions that would help to improve the likelihood of a successful implementation. KPMG’s report, 
released in November 2008, concluded that M-DCPS’ ERP project was at risk of cost and scheduling 
overruns. In addition, KPMG found that the cost and extent of work estimated in the original implementation 
plan had been understated. 

In January 2009, after one and one-half years of difficulties associated with Deloitte’s implementation of 
the ERP system, the School Board authorized a new ERP implementation plan. Under the new plan, the 
District terminated its contract with Deloitte Consulting, effective February 2009, and took control of the 
ERP project. M-DCPS’ Office of Information Technology Services (ITS) assumed control of the ERP 
implementation in February 2009. Of the original $85.4 million budgeted for the ERP project, a total of 
$58.9 million had been paid to Deloitte. This left a balance of $26.5 million for ITS staff to implement the 
project. 

The Organizational Management and Personnel Administration module went live in October 2009, followed 
by the E-Recruiting module in December 2009 and the Finance/Procurement module in January 2010. In 
August 2010, the Pluman Resources module, which included Employee Self Service, went live. The 
implementation of the Payroll module, originally scheduled to go live in January 201 1 , was extended by 
10 months. The extension provided adequate time to train and perform dual-time entry using a phased- 
in approach for 14 payroll cycles. In addition, employees were given ample time to see the new payroll 
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statement and understand the changes incorporated in the new statement. The extension also allowed 
implementation to take place after opening of schools and class sizing were complete. The Payroll module 
went live in November 201 1 . 

In order to facilitate the implementation of the ERP project, ITS conducted training with District offices 
affected by the transition to the new system. Districtwide training on the Payroll module was extensive 
and included the following: 

• Training was provided to the Time Specialist and the Payroll Approver from every location. The 
training focused on familiarizing staff with the new SAP payroll process and with the reports that are 
produced. 

• Additional training was provided at larger or specialized locations, such as Transportation and 
Food Service. 

• SAP Support Delegates were identified by every location as a site-based level of support. The 
delegates were provided with training and materials to assist them in this effort. 

• A SAP Help Hotline/Help Desk handled individual questions from staff when the payroll module went 
live. 

• As part of the system verification and training, Time Specialists entered time into SAP for several 
actual pay periods that had previously been entered and approved in legacy. Once entered into 
the SAP site, supervisors were asked to verify and approve the SAP payrolls. 

• A video comparing a SAP pay statement with a legacy pay statement was posted on the Employee 
Portal. 

• An application on the Employee Portal allowed staff to view or print their own SAP pay statement 
and legacy pay statement from a prior pay period to compare the differences. The site provided 
employees with detailed information on the differences between the two pay statements. All staff 
were required to view the two pay statements and indicate whether or not they understood the 
differences. Their responses were recorded in the event that any discrepancies or issues occurred. 
The site also provided a means for employees to communicate any issues or concerns to the SAP 
Support Team. 

• Flyers showing the new SAP pay statement and the differences between SAP and legacy pay 
statements were made available for printing via the Weekly Briefings system for all locations and 
staff. For those locations where staff may not have had easy access to a computer, the flyers were 
printed and distributed to each employee by location staff. 

• Posters showing the new SAP pay statement and the differences between SAP and legacy pay 
statements were provided to larger locations (such as Transportation sites, Maintenance, Region 
Offices, and the School Board Administration Building). In all, over 70 posters were printed. 

In conclusion, ITS was able to successfully implement all five modules of M-DCPS’ ERP system in less 
than three years. The project was brought in on budget. In addition, ITS’ provision of extensive training 
and support ensured a smooth transition to the new system throughout the District. Although final judgment 
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of the efficacy of the ERP system cannot be made for at least another year, it is important to acknowledge 
ITS’ accomplishments. Staff were able to overcome obstacles associated with the work initially conducted 
by Deloitte Consulting and complete the project in a timely manner and within the District’s original 
budget. 


SUMMARY 

More and more organizations are turning to ERP systems to replace obsolete processes and integrate 
data. But studies have found that a high percentage of ERP implementations are classified as failures. 
Across a wide variety of industries, the majority of ERP projects are over budget, late, or contain less 
than the required features and functions. Many ERP projects are even cancelled prior to completion. 

This Information Capsule summarized 1 0 high profile ERP implementation failures that occurred over the 
last few years. The ERP projects described in this report were all characterized by significant delays or 
budget overruns. After years spent on project implementation, five of the organizations have no functioning 
ERP system in place and five of the organizations are struggling with systems that are not fully functional. 
Seven of the 10 organizations are involved in ongoing lawsuits. One company reached a confidential 
settlement with their software vendor after a two-year legal battle. 

The 10 factors most frequently associated with ERP system failure were also reviewed in this report. In 
most cases, it is impossible to assign blame solely to one party, but in some instances the fault lies mainly 
with software vendors or systems integrators; in others, the organization implementing the ERP system 
engages in practices that contribute to project failure. For example, it is common for software vendors 
and systems integrators to assign inexperienced consultants to ERP projects and significantly 
underestimate project budgets. In other cases, organizations request excessive software customization, 
lack senior management support, do not successfully manage the project, or do not provide employees 
with adequate system training. 

A brief description of Miami-Dade County Public Schools’ (M-DCPS) ERP project was provided. Contrary 
to the many failed experiences chronicled nationwide, M-DCPS’ story is one of success. The District 
originally hired Deloitte Consulting to provide implementation services for the ERP software. One and 
one-half years later, a report published by KPMG, retained by M-DCPS to provide independent project 
monitoring services, concluded that the District’s ERP project was at risk of cost and scheduling overruns. 
The District subsequently terminated its contract with Deloitte Consulting and assumed control of the 
ERP project. M-DCPS’ Office of Information Technology Services was left with only $26.5 million of the 
originally budgeted $85.4 million to implement the project. 

The District’s Office of Information Technology Services (ITS) successfully implemented all five modules 
of M-DCPS’ ERP system in less than three years: Organizational Management and Personnel 
Administration, E-Recruiting, Finance/Procurement, Human Resources, and Payroll. Although final 
judgement of the efficacy of the ERP system cannot be made for at least another year, ITS staff were 
able to complete the ERP project in a timely manner and within the District’s original budget. In addition, 
ITS’ provision of extensive training and support ensured a smooth transition to the new system throughout 
the District. ITS staff overcame the obstacles associated with the work initially conducted by Deloitte 
Consulting. 


All reports distributed by Research Services can be accessed at http://drs.dadeschools.net. 
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